Hi, I have again couple of question for the purpose of LinkModules:
Dinio - Tue Jan 05 11:48:28 EST 2016 |
Re: LinkModules related questions Hi Dinio,
1. DOORS will not restrict you in that way. Is up to you to manage your link modules and your link set. Usually different link modules and different link sets can be used if you are tracing from one module to a different number of modules. In that way you can filter and create views that display different set of objects to aid in the analysis of your requirements. If you want to trace from one module to just one other module then one link module is sufficient, you do not need to create two link modules. But even then you might have a requirement on those 2 modules that one link module is for requirements type "A" for example and the other link module is for requirements type "B". Even if in that scenario will make things a bit difficult for you to maintain it and probably you need to create a bespoke linking utility and script, this might aid you when you filter and analyse your requirements. 2. Is up to you where you want to put the linkset pairing. Remember the link module holds only the linkset pairing and not the links. The links are usually held in the folder where the module is located. Usually it is easy to do something more descriptive rather "satisfies" or "link to" or anything like for link module names as the names mentioned are very generic. When I design the way that my project will look like I have one folder that I keep all my link modules, also I include in the name of the folder at the beginning a a 2 digit number so for the specific number I will name the folder "99 - LinkModules". The 2 digit numbers system will allow me to organise the folders in the order that I want to so if I have a "System" folder and then a "Software" folder I can make sure that the system is always displayed first. Also the numbers will make it easier for the user to navigate because when you talk to someone on the phone is easier to point to a numbered folder without worrying about the naming and confuse the user or take time to find the specific folder. Then in the link module folder I will create the link modules with a notation of "<module from which I would like to link> to <module to I would like to link>" So in that way the link module name is very precise (probably truncate the name of the module "from" and "to" so the link module name is not so big). I found that notation is much more clearer than names like "satisfies" etc. Then in the module that I want to link from I create a link set with the specific target module, link module that I have created and make it mandatory and not overwritten. Then set set the option only to allow links to specific target modules that are in the list. In that case you restrict the user on what it can link to and you can control in which link module the pairing will be created. Then you will not have any issues. 3. You cannot delete objects with incoming links. There is no perm. This is a fundamental design of DOORS as the link on the source object will be incomplete. What you can do you can create a script to do the deletion action that it will follow the links one by one and remove them with the "delete" function then you can delete the object. Kind regards, Costas
|
Re: LinkModules related questions Costas..Aravidis - Wed Jan 06 04:01:15 EST 2016 Hi Dinio,
1. DOORS will not restrict you in that way. Is up to you to manage your link modules and your link set. Usually different link modules and different link sets can be used if you are tracing from one module to a different number of modules. In that way you can filter and create views that display different set of objects to aid in the analysis of your requirements. If you want to trace from one module to just one other module then one link module is sufficient, you do not need to create two link modules. But even then you might have a requirement on those 2 modules that one link module is for requirements type "A" for example and the other link module is for requirements type "B". Even if in that scenario will make things a bit difficult for you to maintain it and probably you need to create a bespoke linking utility and script, this might aid you when you filter and analyse your requirements. 2. Is up to you where you want to put the linkset pairing. Remember the link module holds only the linkset pairing and not the links. The links are usually held in the folder where the module is located. Usually it is easy to do something more descriptive rather "satisfies" or "link to" or anything like for link module names as the names mentioned are very generic. When I design the way that my project will look like I have one folder that I keep all my link modules, also I include in the name of the folder at the beginning a a 2 digit number so for the specific number I will name the folder "99 - LinkModules". The 2 digit numbers system will allow me to organise the folders in the order that I want to so if I have a "System" folder and then a "Software" folder I can make sure that the system is always displayed first. Also the numbers will make it easier for the user to navigate because when you talk to someone on the phone is easier to point to a numbered folder without worrying about the naming and confuse the user or take time to find the specific folder. Then in the link module folder I will create the link modules with a notation of "<module from which I would like to link> to <module to I would like to link>" So in that way the link module name is very precise (probably truncate the name of the module "from" and "to" so the link module name is not so big). I found that notation is much more clearer than names like "satisfies" etc. Then in the module that I want to link from I create a link set with the specific target module, link module that I have created and make it mandatory and not overwritten. Then set set the option only to allow links to specific target modules that are in the list. In that case you restrict the user on what it can link to and you can control in which link module the pairing will be created. Then you will not have any issues. 3. You cannot delete objects with incoming links. There is no perm. This is a fundamental design of DOORS as the link on the source object will be incomplete. What you can do you can create a script to do the deletion action that it will follow the links one by one and remove them with the "delete" function then you can delete the object. Kind regards, Costas
Thanks Constas, but other questions comes in my head based on your answer. First to clarify the notions:
The questions: 1. Is (1) above is true? Does the Every Linkpari contains all the in/out links or only out links? 2. Can we have multiple LinkModuleDescriptors between the same targetModule and LinkModule? (Edit: Checked by myself - We can not but situation 4 is possible). 3. How programatically to find the LinkSet for the given Formal Module. If I have Module mod, and have 2 objects which want to add link between. Is it enough just to make o1->o2 or have to specify explicitly the linked module? 4. And if we define relation ob1->obj2 in the Default Link Module and then add LMD and add the same relation and then delete it from the Default Link Module. The link is still there. Why? We define the same think in different places. |
Re: LinkModules related questions Hi Dinio, The link module holds only the link set. It does not hold the links. You need to see the file structure on the server to understand how it works. Each module is a folder on the server that holds all the objects and all the relations with other objects and other modules (links). In a link module you can also see the relationships between objects, but this is only a view, and is not what it is held in the module. So the actual links are not in the linkmodule. There are not in or out links in the link module it is just a link set. The links are held within the folder where the module is located. So here it is the folder structure
The information for the objects are held in files together with the out links and the in links are held in different file. All those files are encrypted on the server. The link modules have only the information from what module to what module. The link module descriptor is also held in the parent folder of the module so in order to get the information you need to loop in the folder of the module. Now this is important you can only have one link set pairing for a set of modules thus module A can link to module B but the definition of linkset can only be done once. even if you try to select different link modules doors will not let you create a second link set pairing. If you have already created a pairing and you have restricted the outgoing links when you tried to perform the operation you describe o1->o2 then you will get a failure as the default link module is not the one that is defined by the linkset pair. So in this case you need to loop through the folder and get the individual link descriptor, and from the link descriptor get the name of the source and target and then if the source and target is the same from where you want to link to then you can get the name of the link module and do the linking in the form "Object source -> string linkModuleName -> Object target". And this will solve all your problems.
So answers to your final questions 1. Link set pair does not contain any links. 2. You cannot have multiple link module descriptors between the same source and target 3. If you have restricted outgoing links creation then you definitely need to find the link module name.
If you have not restricted the outgoing links creation you can do o1->o2 but this will create a link set in the default link module which is defined on the database level and only if the option of creating default link modules is enable. In that case a link module if it does not already exist will be created in the same folder with the source module and only if the user has create and modify access to the folder. To find the link module then you can do something like that
Target name is the name of the target module and name is the name of the link module. So the answer to your third question is depends...
Now if you want to delete an object with incoming links then what you need to do is simply go through all the incoming links of the object. Open all the source modules in edit mode either exclusive or shareable with lock objects. Then put all the in links in a skip list. Delete all the incoming links by looping through the skip list (this will stop doors crashing if you loop through the links and try to delete them at the same time). Save and close all the source modules and then delete the object.
Hope that helps. Links is a bit complicated subject.
Kind regards,
Costas
|
Re: LinkModules related questions one additional thought, as you also asked "why" different link modules exist. Think of DOORS as a relational database and pretend link modules are the named relations between two entities. If you have two entities "class" and "person" you can have different relations, e.g. "teaches" (person is teacher) and "enrolled in" (person is student). The LMDs / link pairings define the *default* relation, which in this example should be "enrolled in", as there will be a lot more students than teachers and its easier for the editor of the data to click on "teaches" only once than to click on "enrolled in" several times. This example also shows that there is no "best" way to create a link between two objects, so you cannot write a generic "maintain link" script for all purposes. You always need to know the data model and the naming conventions behind the DOORS modules and links and the meaning for the link you want to create, only then you can decide which link module to use to create a link. The only exception is if there is a link pairing from module A to B and this pairing is mandatory. Only then you can know for sure that the author of the data model intended in his design that no other link relation besides the standard relation may be used. |
Re: LinkModules related questions Costas..Aravidis - Wed Jan 06 07:09:16 EST 2016 Hi Dinio, The link module holds only the link set. It does not hold the links. You need to see the file structure on the server to understand how it works. Each module is a folder on the server that holds all the objects and all the relations with other objects and other modules (links). In a link module you can also see the relationships between objects, but this is only a view, and is not what it is held in the module. So the actual links are not in the linkmodule. There are not in or out links in the link module it is just a link set. The links are held within the folder where the module is located. So here it is the folder structure
The information for the objects are held in files together with the out links and the in links are held in different file. All those files are encrypted on the server. The link modules have only the information from what module to what module. The link module descriptor is also held in the parent folder of the module so in order to get the information you need to loop in the folder of the module. Now this is important you can only have one link set pairing for a set of modules thus module A can link to module B but the definition of linkset can only be done once. even if you try to select different link modules doors will not let you create a second link set pairing. If you have already created a pairing and you have restricted the outgoing links when you tried to perform the operation you describe o1->o2 then you will get a failure as the default link module is not the one that is defined by the linkset pair. So in this case you need to loop through the folder and get the individual link descriptor, and from the link descriptor get the name of the source and target and then if the source and target is the same from where you want to link to then you can get the name of the link module and do the linking in the form "Object source -> string linkModuleName -> Object target". And this will solve all your problems.
So answers to your final questions 1. Link set pair does not contain any links. 2. You cannot have multiple link module descriptors between the same source and target 3. If you have restricted outgoing links creation then you definitely need to find the link module name.
If you have not restricted the outgoing links creation you can do o1->o2 but this will create a link set in the default link module which is defined on the database level and only if the option of creating default link modules is enable. In that case a link module if it does not already exist will be created in the same folder with the source module and only if the user has create and modify access to the folder. To find the link module then you can do something like that
Target name is the name of the target module and name is the name of the link module. So the answer to your third question is depends...
Now if you want to delete an object with incoming links then what you need to do is simply go through all the incoming links of the object. Open all the source modules in edit mode either exclusive or shareable with lock objects. Then put all the in links in a skip list. Delete all the incoming links by looping through the skip list (this will stop doors crashing if you loop through the links and try to delete them at the same time). Save and close all the source modules and then delete the object.
Hope that helps. Links is a bit complicated subject.
Kind regards,
Costas
First thanks a lot for the explanations and for the picture because I do no have access to the Doors Server to see the file structure.
So as I understand you say that there is only one set pair between two modules no matter of the Linked Module. So I tried and successfully do
but it is true for one LinkedModule. So between two modules can be created only one LinkedPair. Then I restricted the outgoing links but successively create link with other module.
|
Re: LinkModules related questions Dinio - Wed Jan 06 12:07:21 EST 2016
First thanks a lot for the explanations and for the picture because I do no have access to the Doors Server to see the file structure.
So as I understand you say that there is only one set pair between two modules no matter of the Linked Module. So I tried and successfully do
but it is true for one LinkedModule. So between two modules can be created only one LinkedPair. Then I restricted the outgoing links but successively create link with other module.
Well, it should work exactly like this. I assume that there is a bug in the DOORS version you use. |
Re: LinkModules related questions Dinio - Wed Jan 06 12:07:21 EST 2016
First thanks a lot for the explanations and for the picture because I do no have access to the Doors Server to see the file structure.
So as I understand you say that there is only one set pair between two modules no matter of the Linked Module. So I tried and successfully do
but it is true for one LinkedModule. So between two modules can be created only one LinkedPair. Then I restricted the outgoing links but successively create link with other module.
Check your link if it has been created through a different link module or DOORS has ignored that (do properties on the object). Save the module before you create a link. It might be the case that IBM has put a safeguard and in that case the other link module is ignored. You will need the full path to the link module. |
Re: LinkModules related questions Mike.Scharnow - Wed Jan 06 15:20:15 EST 2016 Well, it should work exactly like this. I assume that there is a bug in the DOORS version you use. Not bugs again....
|
Re: LinkModules related questions Dinio - Thu Jan 07 04:46:07 EST 2016 Not bugs again....
1. inlinks.dtc stores the "in-link" references (LinkRefs) which you always hope are in sync with the outlinks (stored in treedata.dtc of the source module). So the LinkRefs only tell you where a link is coming from, while the "Link" type only is accessible from the source and stores not only the link information, but also link attributes, etc. Note that there are "mirrored links" (which refers to the synchronicity of out- and inlinks), which you can identify by the solid triangle link marker and there are non-mirrored links/linkrefs, which do not have a corresponding in/outlink and you can identify from the non-solid triangle link markers (the one you get in baselines). So the situation is more complex when you take into account versioning - providing traceability above baselines needs careful planning. 2. Yes you will get all LinkModuleDescriptors. Remember LinkModuleDescriptors are not mandatory, so its not a reliable way to find all links. Regards, Mathias |
Re: LinkModules related questions Mathias Mamsch - Thu Jan 07 10:18:16 EST 2016 1. inlinks.dtc stores the "in-link" references (LinkRefs) which you always hope are in sync with the outlinks (stored in treedata.dtc of the source module). So the LinkRefs only tell you where a link is coming from, while the "Link" type only is accessible from the source and stores not only the link information, but also link attributes, etc. Note that there are "mirrored links" (which refers to the synchronicity of out- and inlinks), which you can identify by the solid triangle link marker and there are non-mirrored links/linkrefs, which do not have a corresponding in/outlink and you can identify from the non-solid triangle link markers (the one you get in baselines). So the situation is more complex when you take into account versioning - providing traceability above baselines needs careful planning. 2. Yes you will get all LinkModuleDescriptors. Remember LinkModuleDescriptors are not mandatory, so its not a reliable way to find all links. Regards, Mathias So @Mathias_Mamsch 85b3aa38-6d03-41f0-8c83-a441b8c46b92 what is reliable way to find all links? If I do not find the link in the LMD in the parent folder then I try to search in the Default link module and the link must me there? Am I right? Or the link can be in any other link module? |
Re: LinkModules related questions Dinio - Thu Jan 07 10:50:15 EST 2016 So @Mathias_Mamsch 85b3aa38-6d03-41f0-8c83-a441b8c46b92 what is reliable way to find all links? If I do not find the link in the LMD in the parent folder then I try to search in the Default link module and the link must me there? Am I right? Or the link can be in any other link module? Find all the links from where to where? You can iterate over the links of a module. This will find links realiably unless your modules are somehow corrupt. Regards, Mathias |
Re: LinkModules related questions Mathias Mamsch - Thu Jan 07 11:00:10 EST 2016 Find all the links from where to where? You can iterate over the links of a module. This will find links realiably unless your modules are somehow corrupt. Regards, Mathias Links may not be accurate if whoever runs the script does not have access to some of the modules that are linked or some of the link modules -- you can only report on what you have permissions to -- all the rest is hidden. |